DIY Exercise 12-2: Route messages using JMS queues

Time estimate: 2 hours

Objectives

In this exercise, you continue to build the Visa gift card distribution Mule applications. You will:

·        Conditionally process and route Mule events using different JMS queues.

Import the starting project

Use your solution from exercise 12-1 or import /files/module12/connectors-mod12-various-systems-part1-solution.jar (in the MUFundamentals4.x DIY Files zip that you can download from the Course Resources) into Anypoint Studio.

 

If you have not yet installed the mock-servers dependency, install the dependency located in MUFundamentals4.x DIY Files zip into your local m2 repository to allow the project to run the mock FTP and mock database server you will use for this project. For help, follow the step-by-step Install a Mule application as a dependency walkthrough.

Route the messages using JMS queues

Each partner should use a different JMS queue. Replace all the Flow Reference components in the processVisaGiftCards flow with different JMS message queues, one for each partner type: Food-N-Savings, Meals-N-Go, Online Retail Plus.

 

For testing purposes, use the default virtual JMS server that will be created when the Mule application is deployed. Set each queue name using a property placeholder, so it can be changed later by the Operations team without having to re-write the Mule application(s).

Answer the following questions

·       Is it preferable to send one message per file or one message per record of a file?

·       How do you specify the payload format of the JMS messages?

·       What would you do if the file is too big to fit into memory?

Write out a summary report in the process-visa-gift-cards Mule application

Write out a report of the number of gift cards processed for each partner and which transfers succeeded. Each transfer needs to send a success or fail message back to the process-visa-gift-cards Mule application.

 

The process-visa-gift-cards Mule application will take the response messages from each of the other Mule applications and write out a summary report text file reporting the number of gift cards processed for each partner and the success or fail status of each transfer Mule application.

Answer the following questions

·       What sort of operation do you need to use to retrieve status messages from each partner flow?

Verify your solution

Import the solution /files/mpdule12/connectors-mod12-various-systems-part2-solution.jar deployable archive file (in the MUFundamentals4.x DIY Files zip that you can download from the Course Resources) and compare your solution.

Going further: Refactor the Mule application into separate Mule applications

After testing that all the JMS queues are working correctly, refactor the Mule applications into separate Mule projects, one for each retail partner, and a separate process-visa-gift-cards Mule application for the processVisaGiftCards flow. For each retail partner, debug the process-visa-gift-cards and the retail partner's Mule application at the same time.

Going further: Prototype a Mule domain project

Months have passed, and the bank would like to improve performance. Modify the solution to combine all the Mule applications into one Mule domain that will run inside the Mule Bank network, instead of collocated at each partner's network.

 

In this new refactoring, the distribution of Visa gift card CSV files over JMS queues will occur in the local data center, and then each partner Mule application will distribute the processed gift cards over remote connections:

·       The Food-N-Savings Mule application will make a remote connection to the Food-N-Savings database.

·       The Meals-N-Go Mule application will make a remote connection to the Meals-N-Go FTP server.

·       The Online Retail Plus Mule application will output the final JMS message over a remote TCP connection to the Online Retail Plus Mule application.

Answer the following questions

·       What connector could you use instead of JMS to try to increase system performance for Mule applications in the same domain?

·       What features might be missing with this new connector?

·       Aside from replacing the JMS connector with this new connector, would you need to modify anything else for the entire system to work?

·       What are the advantages and disadvantages of using this other connector?

Going further: Experiment with other messaging connections

Replace the JMS connections with other messaging connections such as VM, Anypoint MQ, or Active MQ and compare behaviors and performance.

Answer the following questions

·       Can different Mule applications in the default Mule domain share a VM queue if they are running on different Mule runtimes?

·       Can different Mule applications in a non-default Mule domain share a VM queue if they are running on different Mule runtimes?

·       What are the limitations and advantages of a VM queue vs. a JMS queue?

Note: You can learn more about scaling VM queues to multiple Mule runtimes in a cluster in the Anypoint Platform Operations: Customer-Hosted Runtimes course and the Anypoint Platform Operations: CloudHub course.

Going further: Use an API-led approach

Refactor your solution to be API-led by creating System APIs and Process APIs to augment and control the lower-level protocols. Write an Experience API for a consumer to receive a gift card on their mobile client.

·       What are the advantages or disadvantages of using an API-led approach?

·       How does IT handle and manage the development lifecycle of all of these projects without wrapping them in APIs or using an API-led approach?

·       With an API-led approach, does IT need to be directly involved in the actual development and delivery of each project?

·       How could IT encourage line of business teams to consume and reuse these APIs, as well as encourage them to share and distribute their own APIs with other teams?

·       Without an API-led approach, how might you separate out business logic for who gets particular gift cards and what type of gift cards?

·       What is the impact on your projects to change gift card distribution business logic versus if you had separate System, Process, and Experience APIs?

·       How many projects and flows need to be changed to integrate all these gift card Mule applications with a new mobile app project, and how does this effort compare to what is needed if you have separate System, Process, and Experience APIs?